Underground

home *** CD-ROM | disk | FTP | other *** search

/ Underground / Underground CD1.iso / crack / Howto3a.txt < prev next >

Wrap

Text File | 1999-01-12 | 25.7 KB | 523 lines

HOW TO CRACK, A TUTORIAL - LESSON 3 (1) by +ORC (the old red cracker) How to crack, an approach LESSON 1 How to crack, tools and tricks of the trade LESSON 2 -> How to crack, hands onn, paper protections LESSON 3 (1/2) How to crack, hands on, time limits LESSON 4 How to crack, hands on, disk-CDrom access LESSON 5 How to crack, funny tricks LESSON 6 (1/2) How to crack, intuition and luck LESSON 7 How to crack windows, an approach LESSON 8 How to crack windows, tools of the trade LESSON 9 How to crack, advanced cracking LESSON A (1/2) How to crack, zen-cracking LESSON B How to crack, cracking as an art LESSON C How to crack INDEX LESSON 3 (1) HOW TO CRACK, HANDS ON - Password protected programs SOME PROBLEMS WITH INTEL's INT The INT instruction is the source of a great deal of the flexibility in the PC architecture, because the ability to get and set interrupt vectors means that system services (included DOS itself) are infinitely extensible, replaceable and MONITORABLE. Yet the Int instruction is also remarkably inflexible in two key ways: - an interrupt handler DOES NOT KNOW which interrupt number invoked it. - the int instruction itself expects an IMMEDIATE operand: you cannot write MOV AX,x21, and then INT AX; you must write INT x21. That would be very good indeed for us cracker... unfortunately many high level language compilers compile interrupts into PUSHF and FAR CALL instruction sequences, rather than do an actual INT. Another method is to PUSH the address of the handler on the stack and do RETF to it. Some protection schemes attempt to disguise interrupt calls, 1) camouflaging the code, 2) putting in substitute interrupt instructions which look harmless and modifying them "on the fly" or 3) replicating whole interrupt routines inside the code. This is particularly frequent in the various "disk access" protection schemes that utilize INT_13 (the "disk" interrupt) and will therefore be thoroughly explained in -> lesson 5. A LITTLE BASIC ASSEMBLER In order to understand the protection schemes and to defeat them, you must acquire a passing knowledge of assembler, the "machine language" code. You can find a lot of good, well explained code for free: viruses are one of the best sources for good "tight and tricky" assembler code. You can find the source code of almost all viruses on the web: oddly all the would be hackers seem to have an aberrant passion for this kind of stuff instead of studying cracking techniques. But there are millions of lines of good explained "commercial" assembler code on the net, just fish it out and study it: the more you know, the better you crack. I'll restrict myself to some observations, sprinkled throughout this tutorial. Let's start with some must_know: ------------------------ STRINGS ---------------------------- The string instructions are quite powerful (and play a great role in password protection scheme). ALL of them have the property that: 1) The source of data is described by the combination DS:SI 2) The destination of data is described by the combination ES:DI 3) As part of the operation, the SI and/or DI register(s) is(are) incremented or decremented so the operation can be repeated. ------------------------- JUMPS ----------------------------- JZ ero means what it says JNZ ero means what it says JG reater means "if the SIGNED difference is positive" JA bove means "if the UNSIGNED difference is positive" JL ess means "if the SIGNED difference is negative" JB elow means "if the UNSIGNED difference is negative" JC arry assembles the same as JB, it's a matter of aesthetic choice CRACKING PASSWORD PROTECTED PROGRAMS Refer to lesson one in order to understand why we are using games instead of commercial applications as learn material: they offer the same protection used by the more "serious" applications (or BBS & servers) although inside files that are small enough to be cracked without loosing too much time. A whole series of programs employ copy protection schemes based upon the possess of the original manual or instructions. That's obviously not a very big protection -per se- coz everybody nowadays has access to a photocopier, but it's bothering enough to motivate our cracks and -besides- you'll find the same schemes lurking in many other password protected programs. Usually, at the beginning of the program, a "nag screen" requires a word that the user can find somewhere inside the original manual, something like: "please type in the first word of line 3 of point 3.3.2". Often, in order to avoid mistakes, the program indicates the first letter of the password... the user must therefore only fill the remaining letters. Some examples, some cracks: --------------------------------------------------- UMS (Universal Military Simulator) version 1 by Dr Ezra SIDRAN (c) 1987 Intergalactic Development European Union: Rainbird Software United States: Firebird Software --------------------------------------------------- This very old EGA program is one of the first I cracked in my youth, and it's very interesting coz it employs a very basilar protection scheme (a "PRIMITIVE"! More than 80% of the protection schemes used to day (January 1996) are directly derived from one of the 12 primitives. The nag screen snaps at the beginning and keeps indefinitely asking your answer, only the use of CTRL+C will bring you out of it, back to DOS. That's a clear sign of older protection schemes: newer schemes let you in for only 3 attempts or even only one, and pop out to the OS if you fail. In UMS, besides, there is no "first letter" aid, a later improvement. The cracking procedure for password protected programs is, first of all, to find out where are stored the letters that you type in. So examine your memory map, find out where the program dwells in memory, do a snap save of these memory areas and a series of snap compares as you type your password in. Strangely enough, in the case of UMS, as you type your password there seems to be no difference at all in the memory locations where this program dwells... yet the data must be somewhere... Usually such a situation is a clear sign that an hooked interrupt is used to hide the data. Checking the hooked vectors you find out the following: vecs 00, 02, 22 are hooked where needs be vecs 34-3D are hooked at xxxx:0 vec 3E is hooked at xxxx:00CA Ha! Let's have a closer look at this bizarre 3E hook. Let's search for some words used in the nag_screen and then let's dump the area where we find them (in UMS that will be at 3E_hook address + 7656) and loo! You'll see the content of the nag screen and, immediately afterwards, ALL the passwords "in extenso", i.e. not encoded, not scrambled, nothing at all... THERE THEY ARE (that's a very old protection scheme indeed). You could now, for instance, easily patch all the different passwords to (for instance) "PASS", and this would work... it's a very primitive protection, as we said, nevertheless the use of a hooked vector as hiding place for the protection code is not yet obsolete... we'll find it elsewhere, in many "more modern" programs. Now let's go deeper and examine the "compare" mechanism, we want to crack, here, not just to patch. Password protected programs (and access protection routines for server and BBS, for that matter) have quite a lot of weak points. The most obvious one (you 'll find out the other when you'll high crack) is that they MUST compare the password of the user with the original one(s). So you do not need to steal a password, you just need to "ear" the echo of the original one in the memory locations used for the compare, or, and that's more correct, to crack the compare mechanism itself so as to make it let you in even with a totally false password. The compare mechanism of UMS can be found setting a breakpoint on the memory range that covers the three locations where the password is stored (and you 'll find these with your search capabilities and with a pair of snap compares): ES:0F8E (here you 'll see a copy of the password that the program is asking) ES:0F5C (here you 'll see a copy of the password that the user types in) INT_3E hook_address + 7656 (here are all the possible passwords in extenso). Here is how the protection scheme looks out: MOV CX,FFFF Charge MAX in CX REPNZ SCASB Scan ES:DI (the user password) NOT CX Now CX holds the number of the character that the user typed in MOV DI,SI Real password offset to DI LDS SI,[BP+0A] User password offset in SI REPZ CMPSB Compares DS:SI with ES:DI (user password and real password) then snap out at CX=0 or at char_different, whichever comes first. Nice, we found the compare schema... how do we crack it now? There are many elegant solutions, but let's remain on a basic level... you look at the code that follows the CMPSB searching the "snapping schema"... here it is immediately afterwards (that's the case in most of the primitives). Remember: we sprung out of the CMPSB check at the first different char, OR at the end of the count of the user chars. Here it is what follows: MOV AL,[SI-01] loads in AL the before_different char of the user password (should be zero) SUB AL,ES:[DI-01] subs with the before_different char of the real password (should be zero) CBW zero flag set, "TRUE", if OK_match Well let's now look for the next JZ near (it's a "74" code) CS:IP 740D JZ location no_good Wait, let's continue a little... is there another check (often you have a double check on DI)... yes there is! CS:IP 7590 JNZ location no_good Cracking such a schema is very easy: you just need to substitute 75 to 74 and 74 to 75: transform your JZ in a JNZ and the JNZ in a JZ... now you will always pass, no matter what you write, unless you exactly guess the password! Now let's quickly crack it: ------------------------------------------------ CRACKING UMS.EXE (by +ORC, January 1996) ren ums.exe ums.ded symdeb ums.ded - s (cs+0000):0 Lffff 74 0D 1E B8 C2 3F (nothing) - s (cs+1000):0 Lffff 74 0D 1E B8 C2 3F (nothing) - s (cs+2000):0 lffff 74 0D 1E B8 C2 3F xxxx:yyyy (this is the answer of the debugger) - e xxxx:yyyy 75 - e xxxx:yyyy+17 74 - w - q ren ums.ded ums.exe ------------------------------------------------- In the debug/symdeb crack above we use as search string the bytes comprising and following immediately the first JZ. I know, I know... we saw them in [Soft-ice] and we could have modified them there, but I'm teaching also pupils who may not have [Soft-ice]. Note that the program is x431A0 bytes long, and therefore has a BX=4 sectors adding to the CX=31A0 in the initial registers... that's the reason I wanted to examine all the sectors (even if I knew that the snap was in sector (cs+2000): that's good practice! If you do not find your string in the first sector you must search for it in the next sectors, till you find it, coz in many programs there may be MORE THAN ONE repetitions of the same schema (more about this double check later). That's it, pupils, that's the way to crack old [UMS.EXE]. Let's go over, now, to more elaborate and more modern password protection schemes. -------------------------------------------------------- LIGHTSPEED, from Microprose (we crack here version 461.01) -------------------------------------------------------- This program, released in 1990, operates a more "modern" variation of the previous scheme. You 'll find this variation in many access routines of remote servers (and this makes it very interesting indeed). Let's begin as usual, with our hooked vectors examination and our snap compares. Hooked vectors: 00, 08, 1B, 22, 23: nothing particular. The snap_comparisons of the main memory area -as you type the password in- gives more than six pages of changing locations... that's clearly much too much to examine. What now? Sit down, have a Martini Wodka (I'm afraid that only Moskovskaja 'll do) and meditate. Get the memory map of the program's layout. Start anew: snap_save (before typing anything in). Type as password "ABCDE". Get the print of the snap compares. Sit down, sip Martini Wodka, relax. You know that the code for A is x41, for B x42, for C x43 and so on... and in the snap_compares, that you made between letters, you 'll have only some locations with these values changing. Focus on these. You 'll soon enough find out that for LIGHTSPEED absolute location (in my computer) 404307, i.e.: relative locations (in my computer) 30BE:F857 or 4043:0007 evoke the characters you type, i.e. something like ----------------------------------------------------- F855 F856 F857 F858 F859... 41 3E first_ready_letter your_1st_letter your_2nd_one... ----------------------------------------------------- Inspecting the same prints, you 'll find out that absolute location 30C64 (imc) or relative location 30BE:F83E evokes the LAST character you typed in. The relative code line is: CS:0097 MOV AX,[BP-08] where SS:F83E = 00+letter_code Now breakpoint at these locations and investigate what's going on (for instance, the instruction that follows is CS:009A MOV [BX], AX and this means that the code of the letter you just typed in will be now copied in BX=F85A. What else can you do? Time to use a little intuition: look for an instruction "CMP AX,000D", which is the typical "IF the user hits ENTER then" instruction, coz "x1D" its the ENTER keystroke. This must be somewhere around here. Ha! You 'll soon enough find the line CS:0073 3D0D00 CMP AX,000D And now the way is open to the crack. But YOU DO NOT NEED ALL THIS! Since the password protection schemes are -as I told you- all more or less the same, I would suggest that you use first of all following trick: in the largest part of the program (use memory map to see where the program dwells) search the "F3A6" sequence, that's instruction REPZ CMPSB. In the case of Lightspd you 'll get as answer FOUR addresses with this instruction: (pgsg=program main segment) pgsg:C6F9 pgsg:E5CA pgsg:E63E pgsg:EAB0 There you are! Only four... have a short look at each of them: you 'll see that the second one (pgsg:E5CA) is the "good" one. The compare mechanism in this program of 1990 it's more or less the same as in 1987'UMS (and do believe me: the same mechanism is still in use to day (1996)! B9FFFF MOV CX,FFFF charge Max in CX F2AE REPNZ SCASB this scans ES:DI (the original password) F7D1 NOT CX so many chars in the original pw 2BF9 SUB DI,CX change DI for compare F3A6 REPZ CMPSB compares DS:SI with ES:DI (real pw with user pw) then snaps out at CX=0 or at char_differs See how easy? They all use the same old tricks the lazy bastards! Here the section is preceded by a small routine to lowercase the user password, coz the original muster is always lowercased. Now you would like, may be, to breakpoint at one of these locations, in order to stop the program "in the snap area" and inspect the snap mechanism... that WILL NOT DO with a "fixed" breakpoint, coz these locations are called by the snap with a different segment:offset numeration as the one you found (that's old dos magic). So you MUST first set a memory_read/write breakpoint on these locations, and then get at them at the snap. Now you can find out the segment:offset used by the snap and only now you'll be able to set a fixed breakpoint (for instance on the NOT CX instruction). Now run the program and breakpoint in: have a dump of the ES:DI and see the original password. How nice! We have now the original password in extenso in our memory dump window. That's the "echo". By the way, there is a whole school of cracking devoted to find and use these echoes... we work on different paths, nevertheless password fishing can be interesting: where are the password stored? From which locations do they come from? A common practice of the protectionists is to hide them in different files, far away, or in hooked vectors, or in SMC parts. This is a program of 1990, that differs in respect to UMS: the passwords are not "hidden" inside a hooked vector, coz that's a pretty stupid protection: any hexdump utility would still permit you to see them. Here the passwords are encoded (albeit in a very primitive manner): looking for them (with memory range breakpoints) you'll quickly find a section of the program code that looks like this: sg:0118 8C 91 9D 95 9B 8D 00 B8 EC 94 9B 8D 8F 8B 9B sg:0128 94 9B 8D 00 AE EC 9C 9B 8A 9B 86 00 A9 EC 91 This is a typical encoded matrix, with clear 00 fences between the encoded passwords. Ha! If all codes where so easy to crack! This is no better than children's crypt! It's a NEG matrix! And there is direct correspondence: 91=6F="o"; 92=6E="n"; 93=6D="m" and so on... Ha! Let's now leave the "hidden" passwords and proceed with our cracking... let's follow the snap procedure after the REPZ CMPSB instruction looking for the "jump to OK" instruction... F3A6 REPZ CMPSB ; compares DS:SI with ES:DI 7405 JZ preserved_AX=0000 <--- Here the first JZ 1BC0 SBB AX,AX ADFFFF SBB AX,FFFF :preserved_AX=0000 8BF3 MOV SI,BX 8BFA MOV DI,DX 5D POP BP CB RETF .... 83C404 ADD SP,+04 0BC0 OR AX,AX 7509 JNZ 0276 <------ And here it is! Now, remembering the UMS crack, you would probably want to change the JZ instruction in a JNZ instruction (you tried it on the fly INSIDE [Soft-Ice] and it did work!), the "74" with a "75" also. And then you would like to change the JNZ instruction in a JZ instruction... Please feel free to try it... it will NOT work! (You will not even find the second JNZ in the program code). You should always be aware of the SMC (self modifying code) protections: parts of the code my be decrypted "on the fly", as needs arise, by the program. The code you modify while the program is running may be different from the code of the "dead" program. Here we have a small "improvement" of the primitive: the same instruction is used as "muster" for manipulation of other parts of the program... if you do change it in a JNZ you get an overlay message and the program pops out with instability! You cannot easily modify the JNZ instruction either, coz the part after the RETF will be compiled "on the fly" by lightspeed, and you would therefore have to search the decryption mechanism and modify the original encrypted byte somewhere... and may be they do encrypt it twice... and then you must hack all night long... very annoying. So do the following: back to the snap, a sip of martini- Wodka and meditate: loo! The only thing that happens after the JZ, is the setting of the AX register to flag *FALSE* (AX=1... that's what the two SBB instructions do) if the snap went out with a non-zero flag... i.e. if you did not know the password. So let's nop the 5 bytes of the two SBB instructions, or, more elegantly, let's have a INC AX, DEC AX, NOP, INC AX, DEC AX sequence instead of the two SBB! There is a good reason to use a sequence of working instructions instead of a series of NOPs: recent protection schemes "smell" patched nops inside the program and trash everything if they find more than -say- three consecutive NOPs! You should always try to choose THE LESS INTRUSIVE and MORE "CAMOUFLAGED" solution when you crack! Eliminating the two SBBs we get our crack! No need to bother with the second JNZ either... the program will work as if you got the password if you have it AND if you do not (that's better as the previous type of crack -seen for UMS- when you crack computer accesses: hereby the legitimate user will not have any suspects 'coz the system will not shut him out... everybody will access: the good guys and the bad ones... that's nice isn't it?). Now let's quickly crack LIGHTSPD: ------------------------------------------------ CRACKING LIGHTSPEED.EXE (by +ORC, January 1996) ren lightspd.exe lightspd.ded symdeb lightspd.ded - s (cs+0000):0 Lffff 2B F9 F3 A6 74 xxxx:yyyy (this is the answer of the debugger) - s (cs+1000):0 Lffff 2B F9 F3 A6 74 (nothing, but do it nonetheless, just to be sure) - s (cs+2000):0 lffff 2B F9 F3 A6 74 (nothing, just to be sure, now it's enough) - e xxxx:yyyy+6 40 [SPACE] 48 [SP] 90 [SP] 40 [SP] 48 - w - q ren lightspd.ded lightspd.exe ------------------------------------------------- All this CMPSB is very common. Some programs, nevertheless, utilize a password protection scheme that is slightly different, and does not rely on a F3A6 REPZ CMPSB instruction. Let's analyze, for instance, the protection scheme used in the first version of Perfect general I from QQP-White wolf, July 1992. When you break in, at the nag screen, you are in the middle of the BIOS procedures, coz the program expects your input (your password, that's is). You 'll quickly find out (MAP MEMORY USAGE!) that [General.exe] dwells in two main areas; Setting breakpoints on memory write you 'll find out that the memory area "queried" by the protection mechanism is xxxx:1180 to xxxx:11C0 where xxxx represents the second of the memory segments where the program dwells. Now do the following (a very common cracking procedure): * Breakpoint on memory range WRITE for the small memory area touched by the program in querying you for the password. * Breakpoint TRACE on the whole memory range of the MAIN CODE. * Run anew everything It's already done! Now it's your intuition that should work a little: Here the last 9 traces (traces [!], not instructions following on a line) before the calling of the procedure sniffing your memory area: -9 xxxx:0185 7425 JZ somewhere, not taken -8 xxxx:0187 2D1103 SUB AX,0311 -7 xxxx:018A 7430 JZ somewhere, not taken -6 xxxx:018C 2DFD04 SUB AX,04FD -5 xxxx:018F 7443 JZ next_trace, taken -4 xxxx:01D4 E85500 CALL funny_procedure -3 xxxx:022C 803E8F8C11 CMP BYTE PTR[8C8F],11 -2 xxxx:0231 750E JNZ somewhere, not taken -1 xxxx:0233 9A0A0AC33E CALL procedure_that_sniffs our_memory_area Well, the call to funny_procedure followed by a byte compare "feels" fishy from very far away, so let's immediately look at this part of the code of [General.exe] :funny_procedure 803E8F8C11 CMP BYTE PTR[8C8F],11 750E JNZ compare_byte 9A0A0AC333 CALL procedure_that_sniffs 0AC0 OR AL,AL 7405 J2 compare_byte C6068F8C2A MOV BYTE PTR [8C8F],2A :compare_byte 803E8F8C2A CMP BYTE PTR [8C8F],2A 7504 JNZ after_ret B001 MOV AL,01 C3 RET You should be enough crack-able ;=), by this lesson, to notice immediately the inconsistency of the two successive instructions MOV 2A and CMP 2A, coz there would be no sense in comparing the "2A" in order to JNZ to after_ret if you just had the 2A set with the precedent MOV instruction... but the first JNZ jumps to the compare WITHOUT putting the "2A" inside. And "2A" is nothing else as the "*" symbol, commonly used by programmer as "OK"! This protection works in the following way (this is the above code explained): - compare holy_location with 11 - jump non zero to compare holy_loc with "*" - else call sniffing protection part - or al,al (al must be zero, else) - jump zero to compare holy_loc with "*" - if al was zero mov "*" inside holy_loc - compare holy_loc with "*" - if there is a difference then JNZ beggar_off_ugly_copier - else ret_ahead_nice_buyer Now let's quickly crack it: ------------------------------------------------ CRACKING GENERAL.EXE (by +ORC, January 1996) ren general.exe general.ded symdeb general.ded - s (cs+0000):0 Lffff 8C 11 75 0E xxxx:yyyy (this is the answer of the debugger) - e xxxx:yyyy+2 EB [SPACE] 09 - w - q ren general.ded general.exe ------------------------------------------------- And in this way you changed the JNZ to the cmp "*" instruction in a JMP to the mov "*" instruction. So no more nag screens, no more protections... serene, placid, untroubled [general.exe]. Well, that's it for this lesson, reader. Not all lessons of my tutorial are on the Web. You 'll obtain the missing lessons IF AND ONLY IF you mail me back (via anon.penet.fi) with some tricks of the trade I may not know that YOU discovered. Mostly I'll actually know them already, but if they are really new you'll be given full credit, and even if they are not, should I judge that you "rediscovered" them with your work, or that you actually did good work on them, I'll send you the remaining lessons nevertheless. Your suggestions and critics on the whole crap I wrote are also welcomed. +ORC an526164@anon.penet.fi